-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: update sprocket to latest WDL crate #46
base: main
Are you sure you want to change the base?
Conversation
This also adds the ability to check/lint URLs
This PR was put back into draft state and will remain as a draft until the This PR will have to be reviewed+merged before those other ones. |
@@ -7,6 +7,17 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 | |||
|
|||
## Unreleased | |||
|
|||
### Changed | |||
|
|||
* Updated WDL crate to latest. This adds support for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't Clay want to keep sprocket
pinned to a release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but that release doesn't exist yet. This PR will be updated to pull an official release once one exists.
I think the language here is fine? Maybe it should specify the version of "latest" once that is out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I would swap latest
with the version when it is known.
if !args.lint && !args.common.except.is_empty() { | ||
bail!("cannot specify `--except` without `--lint`"); | ||
if args.common.shellcheck && !args.lint { | ||
bail!("`--shellcheck` requires `--lint` to be enabled"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the experience we want or should --shellcheck
add --lint
automatically (with a warning)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could go either way I suppose. I don't think I feel strongly on this either way. Could it confuse users if they specify --shellcheck
without --lint
and then they see non-shellcheck lint diagnostics?
"aborting due to previous {error_count} error{s}", | ||
"failing due to {error_count} error{s}", | ||
s = if error_count == 1 { "" } else { "s" } | ||
); | ||
} else if args.common.deny_warnings && warning_count > 0 { | ||
bail!( | ||
"aborting due to previous {warning_count} warning{s} (`--deny-warnings` was specified)", | ||
"failing due to {warning_count} warning{s} (`--deny-warnings` was specified)", | ||
s = if warning_count == 1 { "" } else { "s" } | ||
); | ||
} else if args.common.deny_notes && note_count > 0 { | ||
bail!( | ||
"aborting due to previous {note_count} note{s} (`--deny-notes` was specified)", | ||
"failing due to {note_count} note{s} (`--deny-notes` was specified)", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about this language change. I'm not sure the new proposed language makes it clear that sprocket
is stopping because it has encountered too many errors/notes/warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that this language is an improvement, but maybe it can be improved further. I don't like the aborting
language because in my mind it implies that sprocket
was going to do something else but it's quitting early. This really just controls whether it's a non-zero exit code or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you clarify the behavior here? sprocket
is computing the full set of diagnostics, reporting all of them, and then setting the exit code if any of the requested subtypes has content?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct. The bail!
macro exits the program with a non-zero exit code (IDK what code specifically) and this block of checks is the last thing sprocket
is doing in check/lint
mode. So there is no further computation that might occur if there aren't problems detected. This is the end no matter what.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I initially thought this was related to limiting the number of diagnostics emitted to the first N
. I know that was discussed, but can't recall what the decision was.
Now that I understand it, I agree that the language is an improvement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We did discuss that over slack, but it was decided that limiting to the first N
would likely lead to a bad UX. So we always report the full set of diagnostics, with --local-only
and --single-document
controlling the scope of what's reported (but everything is always computed regardless)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the refresher, the after-effects of the holiday break are quite apparent today.
#[arg(required = true)] | ||
pub paths: Vec<PathBuf>, | ||
#[clap(value_name = "PATH or URL")] | ||
pub file: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A potential nit @adthrasher : is file
the right name for this arg? I couldn't think of a better name...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered commenting on that, but couldn't come up with an alternative I preferred. You could verbosely call it path_or_url
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh. I think I prefer just plain path
to path_or_url
, but don't love either. I'll leave this comment unresolved in case someone else reviewing has a better alternative.
@@ -182,17 +257,17 @@ pub async fn check(args: CheckArgs) -> anyhow::Result<()> { | |||
|
|||
if error_count > 0 { | |||
bail!( | |||
"aborting due to previous {error_count} error{s}", | |||
"failing due to {error_count} error{s}", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"failing due to {error_count} error{s}", | |
"failing with {error_count} error{s}", |
How do you feel about with
instead? I'm not certain that's an improvement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm. Kinda feels like half-dozen of one, 6 of the other to me. I don't see how it clarifies anything, but it doesn't seem worse in any way. I can make that change if you want. I'm fine with it.
This also adds the ability to check/lint URLs
closes #39
sort of closes #45 by providing
--local-only
and--single-document
args which narrow the scope of printed diagnostics. It was decided over slack not to pursue either of the 2 fixes presented in #45 as they were likely undesirable UXs.Before submitting this PR, please make sure: